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(54) Method and system for modifying executable code to add additional functionality 



(57) A system for modifying a compiled executable 
code file by adding patches that add functionality when 
the modified executable code file is executed. The mod- 
ifying is performed without recompiling, relinking or re- 
writing the code file. Adding a patch involves creating a 
patch handler which when executed causes the patch 
statements to be executed, and may involve replacing 
one or more existing compiled instructions in the file with 
patching instructions to transfer flow of execution to the 
appropriate patch handler. The instructions replaced by 
the patching instructions can also be added to the patch 
handler. Patches can also include code statements 
which form a complete module, such as an invokable 
routine, which can be referenced by other patch state- 



ments to cause the module to be executed. Specialized 
trace requests can also be added as patch statements. 
The trace requests will make specified information 
about the current execution of the executable code file 
available to a software developer. Patch statements can 
include variables and expressions that will be evaluated 
in the context of the appropriate current variable scope, 
regardless of whether the scope is defined within the 
patch or by existing compiled instructions. After patches 
have been added, they can be disabled so as to prevent 
their execution without removing the patching instruc- 
tions from the compiled executable file. Patches can al- 
so be qualified with conditions such that the patch will 
be executed only when the conditions are true at the 
time of execution. 
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Description 

[0001] The present invention relates generally to effi- 
ciently creating executable software, and more particu- 
larly to modifying compiled executable files to add addi- 
tional functionality. 

[0002] In the past, creating executable software code 
could be a time-consuming task. The typical code cre- 
ation process involved first creating a source code pro- 
gram (i.e., a series of lines of program statements in a 
high-level computer language) with a text processing 
program, compiling and linking the source code (some- 
times with an intermediate assembling step) to create 
executable code (i.e., a series of machine language in- 
structions) for a specified computer processor, and then 
storing the executable code in an executable file. The 
executable code could then be debugged by executing 
the executable file on the specified computer processor 
to determine if the software performed its task correctly, 
or if instead it had one or more errors (i.e., bugs). If the 
executable code had errors, asoftware developer would 
modify the source code in an attempt to remove the er- 
rors, recompile the source code, and then link the rec- 
ompiled code to produce a new executable file for de- 
bugging. For large software programs, this process was 
iteratively performed a large number of times until all 
known errors were removed. 

[0003] In many cases, the cause of an error (e.g., a 
mistake in the program logic) is not obvious from exe- 
cuting the executable file. Various options existed for a 
software developer to identify errors. For example, a 
software developer could add print statements through- 
out the source code so that as the corresponding exe- 
cutable print instructions are executed (after compiling 
and linking), they would report the current progress of 
the execution. Knowledge of the current execution 
progress assists in identifying the section of the code 
which was executing when an error occurred. In addition 
to merely reporting execution progress, print statements 
can also display the current value of variables or source 
code expressions at specified points throughout the ex- 
ecution. Since the print statements were part of the orig- 
inal compilation/linking process, the variables and ex- 
pressions that were part of the print statements would 
be evaluated in the context of the current variable scope 
(e.g., using the value of a local variable in a currently 
executing function rather than a variable with the same 
name in a different non-executing function), as would 
any other compiled code statement. 
[0004] In addition to print requests, application pro- 
grams known as debuggers were developed to provide 
additional control over execution of executable files. A 
debugger loads executable code into memory and then 
controls execution of the executable code. For example, 
the debugger can execute a single executable code in- 
struction at a time. Alternately, the debugger can exe- 
cute the executable code continuously until a break 
point designated within the debugger is reached. Such 



debuggers can also use additional information stored in 
an executable code file during the compiling and linking 
steps to reconstruct and display the source code lines 
that correspond to the instructions in the executable 

5 code. The display of the source code facilitates control 
by the software developer of the execution of the exe- 
cutable code (e.g., setting a breakpoint at a particular 
point in the source code). When execution of the exe- 
cutable code is stopped, a user can interact with the de- 

10 bugger to view current values of variables and expres- 
sions. In addition, some debuggers allow a user to view 
the effects of temporarily modifying a source code line. 
Nonetheless, although such debuggers can assist with 
locating errors in executable compiled code, recompil- 
es ing and linking is needed to fix errors that are located. 
[0005] In addition to the use of debuggers, other tech- 
niques have been developed to modify the functionality 
of compiled code without requiring a full recompilation 
and linking. One technique involves relinking previously 

20 compiled code with different code than was previously 
used for linking (e.g., using an updated Dynamic-Link 
Library or replacing a stubbed routine with a functional 
routine). In this situation, no changes are made to the 
previously compiled code, but changes in the overall 

25 program functionality can occur due to the different op- 
eration of the newly linked code. However, this tech- 
nique is not typically useful in modifying errors in the 
compiled code (since the compiled code is not changed) 
or in flexibly adding functionality to an executable file at 

30 a desired user-specified location (since only previously 
specified link points can be used for the relinking). 
[0006] Another technique to modify the functionality 
of compiled code without requiring recompilation and 
linking involves rewriting an executable file. Rather than 

35 modifying an existing file, rewriting involves creating an 
entirely new executable compiled file based on an ex- 
isting executable file. Rewriting an executable file does 
allow new functionality to be added to an executable file 
at a user-specified location because new compiled in- 

40 structions can be added to the new file. However, rewrit- 
ing is difficult to perform without adding errors into the 
new file, and the specific mechanisms for adding in- 
structions (e.g., adjusting offsets in existing instructions) 
typically vary on each type of processor. 

45 [0007] When executable code is being created for an 
embedded system (e.g., an embedded controller for 
manufacturing equipment), the problems with software 
code creation are exacerbated. Such embedded sys- 
tems may include only a CPU and memory, without hav- 

50 ing access to other standard computer system compo- 
nents such as a keyboard or display. In addition, stand- 
ard application programs such as text processors and 
debuggers may not be available for an embedded sys- 
tem. In this environment, the source code will typically 

55 be created on a host computer system separate from 
the embedded target system. This allows a user appli- 
cation such as a text processor to create the source 
code. The source code is then compiled for the target 
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embedded computer system and transferred (e.g., over 
a network) to the embedded system for execution and 
debugging. When an error occurs during execution of 
the executable code on the embedded system, the lack 
of standard computer system components and applica- 
tion programs on the target system make it extremely 
difficult to determine the cause of the error. Even obtain- 
ing information about the current state of the execution 
at the time of the error is typically difficult. Moreover, 
even if such information is available, it will need to be 
transferred back to the host computer system where 
modifications to the source code can begin another 
compile/link/transfer/debug cycle. 
[0008] In accordance with one aspect of the present 
invention, a method and system are provided for modi- 
fying a compiled executable code file so as to add func- 
tionality when the modified executable code file is exe- 
cuted. The modifying of the executable code file is per- 
formed without recompiling, relinking or rewriting the ex- 
ecutable code file. In particular, the system allows a user 
to indicate changes to be made to the compiled execut- 
able file, including adding code statements to the com- 
piled executable file and manipulating previously added 
code statements in a variety of ways. Each set of code 
statements which are to be added is referred to as a 
patch, with each statement in a patch being referred to 
as a patch statement. After the patches have been spec- 
ified, the system modifies the compiled executable code 
in a non-transitory manner such that the patch state- 
ments will be performed when the modified executable 
code is executed in the future. This manner of modifica- 
tion allows the traditional compile/link/debug cycle to be 
avoided, thus providing significant time savings. 
[0009] Adding a patch to a compiled executable code 
file involves creating a patch handler which when exe- 
cuted causes the patch statements to be executed and 
which may additionally perform various housekeeping 
functions. The patch statements may be stored in an ex- 
ecutable machine-independent non-compiled format, 
and if so are interpreted when executed on a target com- 
puter. Adding a patch may also involve replacing one or 
more existing compiled instructions in the compiled ex- 
ecutable code file with patching instructions which, 
when executed, will transfer flow of execution to the ap- 
propriate patch handler loaded in memory. When a 
patch is intended to be executed in addition to the ex- 
isting compiled instructions (rather than substituting for 
one or more instructions), the existing instructions re- 
placed by the patching instruction can be added to the 
patch handler so that they will be executed in addition 
to the patch statements. The patching instructions can 
directly identify the memory location of a patch handler, 
such as with a transfer instruction. Alternately, the 
patching instructions can include a unique reference to 
the appropriate patch handler, and if so the appropriate 
memory location for the referenced patch handler will 
not be determined until the time of execution. Patches 
can also include code statements which form a com- 



plete module, such as an invokable routine, which can 
be referenced by other patch statements to cause the 
module to be executed. In addition, patch statements 
can include variables and expressions that will be eval- 

5 uated in the context of the appropriate current variable 
scope, regardless of whether the scope is defined within 
the patch or by existing compiled instructions. Finally, 
specialized trace requests can also be added to the 
compiled executable code as patch statements. The 

10 trace requests will make specified information about the 
current execution of the executable code file available 
to a software developer, such as by storing it on a local 
trace log file or transmitting it electronically. After patch- 
es have been added, they can be disabled so as to pre- 

15 vent their execution without removing the patching in- 
structions from the compiled executable file. Patches 
can also be qualified with conditions such that the patch 
will be executed only when the conditions are true at the 
time of execution. 

20 [0010] In accordance with one aspect of the present 
invention, the system modifies on a target computer a 
compiled file executable on the target computer, with the 
compiled file including a plurality of compiled instruc- 
tions. The modifying is performed under control of a 

25 source computer, and it involves first loading the com- 
piled file onto the target computer and then receiving an 
indication to modify the compiled file by adding at least 
one instruction to be executed upon execution of the 
compiled file. The system then creates a patch group 

30 having instructions including the indicated instructions. 
The system then modifies the compiled file on the target 
computer by replacing an instruction in the compiled file 
with a patch instruction, and loads the patch group into 
a portion of memory on the target computer distinct from 

35 the memory in which the compiled file is loaded. The 
system then executes on the target computer the in- 
structions in the modified compiled file by, when an in- 
struction to be executed is the patch instruction, indicat- 
ing one of the plurality of instructions in the loaded patch 

40 group as a next instruction to be executed. 

[0011] For a better understanding of the present in- 
vention and to show how the same may be carried into 
effect, reference will now be made by way of example 
to the accompanying drawings, in which:- 

45 [0012] Figure 1 is a block diagram illustrating an em- 
bodiment of the Code Patcher system of the present in- 
vention. 

[0013] Figures 2A and 2B illustrate an example of 

patched software code. 
50 [0014] Figures 3A and 3B illustrate examples of 

source code in an executable computer-independent 

non-compiled parse tree format. 

[0015] Figure 4 is an exemplary flow diagram of an 

embodiment of the Command Subsystem routine. 
55 [0016] Figure 5 is an exemplary flow diagram of an 

embodiment of the Process Patch Request subroutine. 

[0017] Figure 6 is an exemplary flow diagram of an 

embodiment of the Patching Subsystem routine. 
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[0018] Figure 7 is an exemplary flow diagram of an 
embodiment of the Code Fragment Executables Sys- 
tem routine. 

[0019] Figure 8 is an exemplary flow diagram of an 
embodiment of the Patch Interpreter Subsystem rou- 
tine. 

[0020] Figure 9 is an exemplary flow diagram of an 
embodiment of the Execute Patched Executable Code 
subroutine. 

[0021] An embodiment of the present invention pro- 
vides a method and system for modifying a compiled 
executable code file so as to add functionality when the 
modified executable code file is executed. The modify- 
ing of the executable code file is performed without rec- 
ompiling, relinking or rewriting the executable code file. 
In particular, the Code Patcher system loads compiled 
executable code into memory on a target computer, and 
allows a user to indicate patches to be made to the com- 
piled executable file. These patches can include adding 
code statements (i.e., compiled instructions or lines of 
source code) to the compiled executable file. In one em- 
bodiment, the source code lines corresponding to the 
compiled executable instructions in the file can be 
shown, and the user can indicate the changes to be 
made in the displayed source code. After the patches 
have been indicated, the Code Patcher system modifies 
the compiled executable code in a non-transitory man- 
ner such that the patches will be performed when the 
modified executable code is executed in the future. This 
manner of modification allows the traditional compile/ 
link/debug cycle to be avoided, thus providing significant 
time savings. 

[0022] Figure 1 illustrates an embodiment of a Code 
Patcher system 1 33 in which the patching of a compiled 
executable code file occurs on a host computer system 
1 00 that is separate from a target computer system 1 50 
on which the patched executable code is to be executed. 
Compiled executable code files to be patched contain 
compiled instructions which are executable as native 
code on the CPU of target computer system 150, and 
which may or may not be executable as native code on 
the CPU of host computer system 100. In addition, in 
the illustrated embodiment the target computer system 
150 has a RISC processor in which all instructions are 
the same length, so one compiled instruction will require 
the same memory space as another compiled instruc- 
tion. Moreover, code statements are converted into a 
machine-independent non-compiled format that will be 
executed interpretively on the target computer system 
150. Those skilled in the art will appreciate that code 
statements could alternatively be compiled and that the 
Code Patcher system 1 33 is not limited to patching code 
for RISC processors. 

[0023] The host computer system 100 includes a CPU 
1 1 0, input/output devices 1 20, a memory 1 30, and a bus 
105. The input/output devices include a storage device 
126, a network connection 122, a display 124, and a 
keyboard 125. The Code Patcher system 133 is execut- 



ing in memory 130, and can be used to patch compiled 
executable code files such as compiled executable code 
file 132 stored on the storage device 126. The Code 
Patcher system 1 33 can also be stored on a storage de- 

5 vice (not shown) such as storage device 1 26 before be- 
ing loaded into memory 130, and the compiled execut- 
able code file 1 32 may also be loaded into memory 1 30 
to assist operation of the Code Patcher system (e.g., for 
display to a user). 

w [0024] The target computer system 150 similarly in- 
cludes a CPU 1 60, input/output devices 1 70, the mem- 
ory 180, and a bus 155. The input/output devices 170 
include a storage device 1 71 and a network connection 
172. A Patch Interpreter Subsystem 181 is executing in 

15 memory 180 to assist in the execution of one or more 
patched executable code files on target computer sys- 
tem 150. The executable code file 132 is loaded into 
memory 1 80 when it is to be executed. After the execut- 
able code file is patched and becomes patched execut- 

20 able code file 182, the patch handlers 184 and code 
fragment executables 186 that are associated with the 
patched executable code file are also loaded into mem- 
ory 180. The memory 180 also includes some or all of 
a Link Translation Table 188 in which current memory 

25 locations associated with various identifiers are stored, 
and of a Trace Log 189 in which information will be 
stored by the Patch Interpreter Subsystem 181 for later 
retrieval. In an alternate embodiment, Link Translation 
Table 1 88 and Trace Log 1 89 could be stored on storage 

30 device 171 and be accessed by Patch Interpreter Sub- 
system 181 only when needed. The Patch Interpreter 
Subsystem 181, patched executable code file 182, 
patch handlers 184, and code fragment executables 
1 86 can also be stored on a storage device (not shown) 

35 such as storage device 171 before being loaded into 
memory 180. 

[0025] When the Code Patcher system 1 33 is first in- 
voked, the Command Subsystem 134 provides a user 
interface to a user (not shown) of the host computer sys- 

40 tern 1 00. The Command Subsystem 1 34 allows the user 
to specify a compiled executable code file that is to be 
patched, such as code file 132. The Command Subsys- 
tem 134 then loads information from executable code 
file 132 (e.g., from the symbol table) to allow a corre- 

45 spondence to be established between the compiled ex- 
ecutable code instructions in the file and the original 
source code lines (not shown) from which the compiled 
executable code was created. The Command Subsys- 
tem 134 then displays the source code to the user and 

50 allows the user to specify a variety of commands. 

[0026] After specifying compiled executable file 132, 
a user can use the Command Subsystem 1 34 to modify 
the file by specifying patches. Each set of code state- 
ments which are to be added is referred to as a patch, 

55 with each added code statement in a patch referred to 
as a patch statement. Executable code which has been 
patched (i.e., modified by having a patch added) is sim- 
ilarly referred to as patched code. As is explained in 
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greater detail below, adding a patch to a compiled exe- 
cutable code file involves first creating an executable 
patch handler which causes the patch statements to be 
executed (and which may additionally perform various 
housekeeping functions) and then replacing one or 
more existing compiled instructions in the file with a 
patching instruction to transfer flow of execution to the 
patch handler. 

[0027] In the illustrated embodiment, patch state- 
ments are stored in an executable machine-independ- 
ent non-compiled format, and are interpreted (i.e., inter- 
pretively evaluated) by an evaluator when executed on 
target computer system 150. Patch Interpreter Subsys- 
tem 181 acts as an evaluator in the illustrated embodi- 
ment. Evaluators can be efficiently provided to a variety 
of target computer systems by cross-compiling an ex- 
isting evaluator for each of the target systems. In an al- 
ternate embodiment, patch statements are stored as the 
original lines of source code and a source code inter- 
preter (not shown) on target computer system 150 is 
used to interpret the patch statements. In yet another 
embodiment, patch statements are compiled for target 
computer system 1 50 before execution and are then ex- 
ecuted natively on the target computer system. 
[0028] A specified patch can take a variety of forms, 
such as substituting one or more new code statements 
for one or more existing compiled instructions or lines 
of source code. After they are substituted for, existing 
compiled instructions will no longer be executed. Rather 
than substituting new code statements, a specified 
patch can also be added such that it is executed in ad- 
dition to the existing compiled instructions, including 
even the instructions replaced by patching instructions. 
This is accomplished by adding the replaced instruc- 
tions to the patch handler for the patch. Multiple lines or 
instructions can be included in a patch, even when sub- 
stituting for a single instruction or when no instructions 
are being substituted for. Some patches include code 
statements which form a complete module, such as an 
invokable routine. If such a module is being added so 
that it can be invoked by other code statements, rather 
than to be directly executed at a designated location, it 
is not necessary to use patching instructions to execute 
the module. Instead, other patch statements can refer- 
ence the module and thus transfer flow of execution to 
the module. 

[0029] Other patches include one or more code state- 
ments which do not form a complete module, referred 
to as a code fragment. Such patches will typically re- 
quire that a patching instruction be added so that flow 
of execution reaches the code fragment. However, if a 
patch handler including a code fragment is referenced 
by another patch handler, the code fragment may not 
directly require a patching instruction for it to be execut- 
ed. In addition, patch statements can include variables 
and expressions that will be evaluated in the context of 
the appropriate current variable scope, regardless of 
whether the scope is defined within the patch or by ex- 



isting compiled instructions. Access to various informa- 
tion for the compiled executable code file to be patched, 
such as the symbol table, may be needed to resolve ref- 
erences to variables. 

5 [0030] In addition to adding code statements, special- 
ized trace requests can also be added to a compiled ex- 
ecutable code file as patch statements. For some target 
computer systems, such as embedded systems without 
a display, it can be difficult to gather information about 

10 execution of executable code since traditional output 
mechanisms (e.g., print statements) are unavailable or 
are difficu It to use. The trace requests will store specified 
information about the current execution of the executa- 
ble code file in a manner that is accessible to a software 

15 developer. For example, if the executable code file is 
being executed on an embedded computer system, the 
trace mechanism can store execution information in a 
trace log file on the embedded computer system for later 
retrieval, or can transmit the information to a separate 

20 computer system for access there. The specified infor- 
mation for a trace request can also include variables and 
expressions that will be evaluated in the context of the 
current variable scope at the time of their execution. In 
addition to reporting the current values of variables and 

25 expressions, the trace requests can be used to track 
each time that a particular instruction or block of code 
is executed. For example, the first instruction in an in- 
vokable procedure can be patched with a trace request 
indicating the current values of the procedure parame- 

30 ters. 

[0031] When a patch is to be added to compiled exe- 
cutable code file 132, the user indicates the patch state- 
ments for the patch as well as where the patch is to be 
added (e.g., in a particular function or at a specific 

35 source code or compiled instruction location). In the il- 
lustrated embodiment, a patching instruction need re- 
place only a single existing instruction since all RISC 
instructions are the same size. The user also specifies 
whether the patch is to substitute for existing compiled 

40 instructions or is to be added in addition to the existing 
instructions. In addition, when a patch is being added in 
addition to existing instructions, it is determined or spec- 
ified whether the patch is to be added before or after the 
existing instructions. When a function is indicated as the 

45 patch location, the patch is added at the first instruction 
for the function (i.e., the patching instruction replaces 
the first instruction for the function). When a source code 
line is indicated, the Command Subsystem 134 identi- 
fies the one or more corresponding compiled instruc- 

50 tions. If multiple instructions correspond to a source 
code line, one or more of the compiled instructions are 
selected to be replaced by the patching instruction. The 
determination of whether the patch is to be added before 
or after the existing instructions may affect which of the 

55 multiple corresponding instructions are selected (e.g., if 
the patch is added before the instructions, selecting the 
first of the multiple corresponding instructions). 
[0032] The Command Subsystem 1 34 also allows the 
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user to perform actions on existing patches, such as to 
group patches together and to manipulate them either 
individually or as a group. For example, a patch previ- 
ously added to the compiled executable code file can 
be disabled so as to prevent its execution. Patches can 
also be qualified with conditions such that the patch will 
be executed only when the conditions are true at the 
time of execution. In addition, different patches can be 
grouped together and each group can be manipulated 
in the same manner as a single patch. For example, all 
patches in a group can be enabled or disabled, or can 
be saved for later use. This ability to group, disable/en- 
able, and qualify patches without recompiling the file al- 
lows trace requests to be turned on or off in a simple 
and efficient manner, greatly simplifying debugging. Fi- 
nally, a user can also use the Command Subsystem 1 34 
to retrieve and view previously created trace informa- 
tion, such as from a trace log. 

[0033] After all the patches have been specified and 
the user is ready to execute the code file 1 32 as patched, 
the Command Subsystem 134 notifies a Patching Sub- 
system 136 of the patches and notifies a Code Fragment 
Executables Subsystem 138 of the code statements 
from the patches. The Code Fragment Executables 
Subsystem 1 38 converts each sequence of one or more 
code statements it receives into a code fragment exe- 
cutable 186 in an executable machine-independent 
non-compiled format. Code fragment executables can 
be executed in an interpreted manner on any target sys- 
tem with an evaluator for the format. In one embodiment, 
the code fragment executables are stored as parse 
trees, as is illustrated further with respect to Figures 3A 
and 3B. Each code fragment executable will be associ- 
ated with the corresponding code file being patched, 
and will also have a unique identifier by which it can be 
referenced. For example, other statements can use the 
unique identifier for a code fragment executable repre- 
senting a module to invoke the module. 
[0034] After creating the code fragment executables 
186 for the code statements in the patches, the Code 
Fragment Executables Subsystem 138 then transfers 
the created code fragment executables to target com- 
puter system 150 and updates Link Translation Table 
1 88. Link Translation Table 1 88 includes a reference for 
each symbol in each of the code fragment executables 
1 86 which can be referenced by statements outside the 
code fragment executable (e.g., the unique identifier for 
a code fragment executable and any exported symbols 
that can be referenced outside the code fragment exe- 
cutable). Those skilled in the art will appreciate that in 
an alternate embodiment, Link Translation Table 188 
could be stored in an alternate location such as on the 
host computer system 100. In addition, those skilled in 
the art will appreciate that the code fragment executa- 
bles 186 could initially be stored on storage device 126 
before being transferred, and could be transferred di- 
rectly to memory 1 80 or first to storage device 1 71 . 
[0035] When the Patching Subsystem 136 receives 



notification of the patches from the Command Subsys- 
tem 134, the Patching Subsystem 136 creates the ap- 
propriate patch handlers 184 and places patching in- 
structions in the appropriate locations in the compiled 

5 executable file 182. In addition, in some embodiments, 
the Patching Subsystem 136 can allocate and deallo- 
cate computer system resources on the target computer 
system 150 needed for the patch handlers 184 (e.g., 
memory in which to load the patch handlers). The Patch- 

10 ing Subsystem 136 first transfers the compiled execut- 
able code file 132 to the target computer system 150. 
After creating the patch handlers 1 84, the Patching Sub- 
system 136 transfers the patch handlers 184 to the tar- 
get computer system 1 50, and updates Link Translation 

15 Table 188 as necessary to include references for the 
patch handlers 184. The Patching Subsystem 136 also 
modifies the compiled executable code file on the target 
computer to include the patching instructions, thus cre- 
ating patched compiled executable code file 1 82. Those 

20 skilled in the art will appreciate that the patch handlers 
184 could initially be stored on storage device 126 be- 
fore being transferred, and could be transferred directly 
to memory 1 80 or first to storage device 1 71 . 
[0036] In particular, at each location in the executable 

25 code file 1 32 where a patch is to be added, the Patching 
Subsystem 136 replaces an existing compiled instruc- 
tion with a patching instruction, thus removing the re- 
placed instruction from patched compiled executable 
file 1 82. Those skilled in the art will appreciate that in an 

30 alternate embodiment, an already-patched code file 
such as file 182 could have additional patches added. 
In that embodiment, an old patching instruction could be 
selected as the instruction to be replaced with a new 
patching instruction. If the new patch is intended to sup- 

35 plement rather than substitute for the previous patch, 
the replaced old patching instruction can be added to 
the new patch handler so that the old patch handler will 
be also executed. Each patching instruction alters the 
flow of execution to an appropriate patch handler so that 

40 the patch statements for the patch will be executed. 
[0037] In one embodiment, each path has a distinct 
patch handler, while in an alternate embodiment a single 
patch handler can handle all patches. Thus, when the 
flow of execution reaches a patching instruction, execu- 

45 tion will be transferred to and will continue at the appro- 
priate patch handler. In some embodiments, the patch- 
ing instructions are transfer statements (e.g., jump, 
goto, branch, call, etc.) which specify an explicit memory 
location (either directly or via an offset) in which the 

50 patch handler will be executed. In alternate embodi- 
ments, the patching instructions include a unique refer- 
ence to the appropriate patch handler, and the appro- 
priate memory location for the referenced patch handler 
is determined from LinkTranslation Table 1 88 at the time 

55 of execution. In yet other embodiments, the patching in- 
structions are trap instructions, and the appropriate 
memory location for the referenced patch handler is de- 
termined from a return Program Counter map. Thus, in 
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these embodiments the patching of compiled executa- 
ble file 132 is performed without recompiling, relinking 
or rewriting the file. 

[0038] In addition to inserting patching instructions, 
Patching Subsystem 136 must also create appropriate 
patch handlers 1 84 so that the patch statements are ex- 
hibited when flow of execution is transferred to the patch 
handler. Each patch handler 184 will first save the cur- 
rent state of execution (e.g., register and stack values) 
if necessary, and then include the code fragment exe- 
cutables and/or trace requests to be executed for the 
patch. If the patch is to be added to compiled executable 
code 132 rather than substituting for the compiled in- 
struction replaced by the patching instruction, the re- 
placed instruction must also be added to the patch han- 
dler so that it will be executed. For example, if the patch 
is to be added after the replaced instruction, then the 
replaced instruction would be added at the beginning of 
the patch handler before any of the patch statements. 
Alternately, if the patch is to be added before the re- 
placed instruction, the replaced instruction would in- 
stead be added after the patch statements. Finally, the 
patch handler will, if necessary, restore the saved state 
of the computer and will then return the flow of execution 
to the instruction in the compiled executable code after 
the patching instruction. 

[0039] Similarly to the created code fragment execut- 
ables 1 86, each patch handler 1 84 will be uniquely iden- 
tified in some way so that it can be referenced by its 
associated patching instruction. In one embodiment, a 
patch handler will always be loaded at a specific location 
in memory 1 80 on target computer system 1 50, and thus 
the patching instruction can explicitly indicate that mem- 
ory location when the patching instruction is added to 
the patched compiled executable file 182 by the Patch- 
ing Subsystem 136. This memory 180 location can be 
identified at the time the patch handler 184 is created if 
the Patching Subsystem 136 performs memory man- 
agement for the target computer system 1 50 in which it 
can allocate and deallocate blocks of memory. Alter- 
nately, the Patching Subsystem 136 could request that 
the target computer system 150 allocate a block of 
memory 180 and provide the memory location informa- 
tion to the Patching Subsystem 136. In an alternate em- 
bodiment, patch handlers 184 are loaded into different 
locations of memory 180 with each execution of the 
patched executable code file 182. In that embodiment, 
Link Translation Table 1 88 can be used to map a unique 
identifier for each patch handler 184 to its current loca- 
tion in memory 1 80. In a similar manner, code fragment 
executables 186 can be stored with patch handlers 184 
and loaded into the memory block for the patch han- 
dlers, or can instead be loaded into separate locations 
in memory 180. If loaded separately in memory 180, a 
patch handler can merely reference a unique identifier 
for a code frag ment executable, and Link Translation Ta- 
ble 188 can be used to identify the current memory lo- 
cation at which to access the code fragment executable. 



In another embodiment, patch handlers 184 and code 
fragment executables 186 are loaded into different lo- 
cations of memory 180 with each execution of the 
patched executable code file 1 82, but rather than using 
5 Link Translation Table 188 the patched compiled exe- 
cutable file 182 is modified before each execution so 
that identifiers are replaced with the current memory lo- 
cation for the associated item. 

[0040] When the patched executable code file 1 82 is 

10 to be executed, the Patch Interpreter Subsystem 1 81 on 
the target computer system 150 controls the execution. 
In particular, the Patch Interpreter Subsystem 181 en- 
sures that compiled instructions are executed as com- 
piled native code on target computer system 1 50, while 

15 patch statements (if stored in machine-independent 
form) are interpreted. The Patch Interpreter Subsystem 
181 also uses Link Translation Table 188 to resolve ref- 
erences to symbols, modules, code fragment executa- 
bles, and patch handlers as necessary. Thus, if a patch- 

20 ing instruction merely references the unique identifier for 
a patch handler 184, the Patch Interpreter Subsystem 
181 will identify the memory location of the patch han- 
dler and transfer flow of execution there rather than try- 
ing to execute the patching instruction as native code. 

25 As trace requests are encountered during execution, the 
specified information for the trace request is stored in 
an appropriate manner, such as in Trace Log 189. The 
Patch Interpreter Subsystem 181 performs its interpret- 
ed evaluation in a manner so as to ensure that variables 

30 and expressions are evaluated in the context of the ap- 
propriate current variable scope. In one mode, the Patch 
Interpreter Subsystem 181 works independently without 
external influence. In an alternate mode, a user on the 
host computer system 1 00 can use the Command Sub- 

35 system 1 34 to interact with Patch Interpreter Subsystem 
181 and to control execution of the patched executable 
file 182. 

[0041] In one embodiment, the target computer sys- 
tem 150 is an embedded computer system, the Code 

40 Patcher system 1 33 is part of a debugger on the distinct 
host computer system 100, and the compiled executa- 
ble file 1 32 is a terminal emulator to be executed on the 
embedded system. In this embodiment, the Code 
Patcher system 1 33 allows a user to perform normal de- 

45 bugging functions (e.g., single stepping through a com- 
piled program) but also allows the user to interactively 
modify an existing compiled executable code file in a 
permanent manner without requiring a compile/link/ 
transfer/debug cycle. The user can also manipulate the 

50 patches in a variety of ways in this embodiment. For ex- 
ample, a patch can be added to the compiled executable 
code file but can be disabled. In this situation, the func- 
tionality added by the patch is not executed while the 
patch is disabled, either by replacing the patch with the 

55 original patched instruction or by indicating to the Patch 
Interpreter Subsystem 181 to not execute the patch 
statements. In addition, different patches can be 
grouped together and each group can be manipulated 
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in the same manner as a single patch. For example, all 
patches in a group can be enabled or disabled, or can 
be saved for later use. Patches can also be qualified 
with conditions such that the patch will be executed only 
when the conditions are true at the time of execution. 
[0042] In addition to significantly reducing the time 
needed to create source code, the Code Patcher system 
1 33 can be used for a variety of other purposes. For ex- 
ample, an executable code file may have been incom- 
plete when compiled. In this situation, references to 
symbols (e.g., variables or functions) may have been 
stubbed at the time of compilation. The Code Patcher 
system 133 can be used to replace the stubs with refer- 
ences to code fragment executables. In addition, addi- 
tional functionality can be added even to compiled exe- 
cutable code files that lack errors. For example, a graph- 
ical user interface could be added to an executable code 
file with only a command-line interpreter, or new func- 
tionality can be added to handle inputs or situations not 
anticipated at the original time of compilation. Those 
skilled in the art will appreciate that any such type of 
functionality can be added using the Code Patcher sys- 
tem 1 33. Those skilled in the art will also appreciate that 
computer systems 100 and 150 are merely illustrative 
and are not intended to limit the scope of the present 
invention. The computer systems may contain addition- 
al components or may lack some illustrated compo- 
nents. Accordingly, the present invention may be prac- 
ticed with other computer system configurations, includ- 
ing a single computer system. 

[0043] As an illustrative example of patching compiled 
executable code, consider Figures 2A and 2B. Figure 
2A illustrates sequences of compiled instructions from 
a compiled executable code file. For readability, a cor- 
responding source code line is shown for each instruc- 
tion. Those skilled in the art will appreciate that the par- 
ticular source code lines are merely illustrative. Figure 
2B illustrates the same compiled executable code file 
after various patches have been added. In particular, 
five patches, including a code fragment executable 
module, have been added to the original compiled exe- 
cutable code file. 

[0044] Patch 1 demonstrates a patch that adds a trace 
request before instruction N. As is shown in Figure 2B, 
instruction N is replaced in the compiled executable 
code file with a patching instruction that indicates to 
transfer flow of execution to a patch handler for Patch 
1 . When execution is transferred to the patch handler 
for Patch 1, the patch handler first saves the current 
state of the target system on which execution is occur- 
ring. The patch handler then issues a trace request for 
a designated string of information. The original patched 
instruction, instruction N, is then executed in the patch 
handler. Thus, Patch 1 executes the trace request in ad- 
dition to, rather than substituted for, the replaced in- 
struction N. After executing instruction N, the original 
state of the computer system is then restored before the 
flow of execution is returned to instruction N+1 . Those 



skilled in the art will appreciate that an execution such 
as the trace request can be performed in a variety of 
ways, such as by writing the specified information to a 
file or by sending the information to another computer, 

5 such as in a message object or as text in an email mes- 
sage. Alternately, trace information can be output using 
any other communication means (e.g., pager, cellular 
phone, display device, etc.). Note that although the trace 
request in Patch 1 did not include any variables or ex- 

10 pressions to be evaluated, instruction N will require the 
evaluation of the variables a and c. This evaluation will 
occur in the context of the appropriate current variable 
scope. 

[0045] Patch 2 reflects a patch which replaces instruc- 
ts tion N+3 with multiple patch statements, including both 
a trace request and a code fragment executable. Patch 
2 also demonstrates a patch that substitutes for an ex- 
isting instruction rather than adding patch statements, 
and thus existing instruction N+3 will be not executed in 
20 the patched executable code file. When flow of execu- 
tion is transferred to the patch handler for Patch 2, the 
patch handler first saves the current target computer 
system state. The-patch handler then executes the 
trace request and the code fragment executable as 
25 shown. Note that this trace request will require the eval- 
uation of variable a, which will be performed in the con- 
text of the appropriate current variable scope. The code 
fragment executable will be executed in an interpreted 
manner. After executing the various instructions in the 
30 patch handler, the original computer system state is re- 
stored before returning flow of execution to instruction 
N+4. 

[0046] As is shown in Figure 2B, the code fragment 
executable module labeled FN2 has also been added 
35 as part of the patch process. Patch 3 adds patch state- 
ments before instruction N+6, including a call to the 
newly created module. Patch 3 also illustrates that mul- 
tiple code statements can be executed within a patch 
handler (limited only by available memory on the target 
40 computer system). After flow of execution transfers to 
the patch handler for Patch 3, the appropriate computer 
system state is first saved. Next, the code fragment ex- 
ecutable for the code statement 'b=b-1' is executed in 
an interpreted manner. The next patch statement calls 
45 module FN2 with the variable b as a parameter. Flow of 
execution will then transfer to the code fragment exe- 
cutable for module FN2, at which time instructions M, 
M+1 , and M+2 will be executed in sequence in an inter- 
preted manner. Upon execution of the return statement 
50 in instruction M+2, the flow of execution will return to 
instruction N+6 in the patch handler for Patch 3. After 
restoring state for Patch 3, the flow of execution will re- 
turn to instruction N+7 in the patched compiled execut- 
able code file. Those skilled in the art will appreciate that 
55 each of the patch handlers can return flow of execution 
to the compiled instructions in a variety of ways, such 
as using a return statement or explicitly using the mem- 
ory location of the next compiled instruction. In addition, 
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in one embodiment each code statement has aseparate 
code fragment executable, while in another embodi- 
ment the various code statements in a patch handler are 
combined into a single code fragment executable. 
[0047] Finally, Patch 4 illustrates that compiled func- 
tions can be patched and traced in a manner similar to 
that of-any other compiled instruction. For example, if a 
user desires to trace all invocations of the function FN1 , 
Patch 4 can be added before the first instruction of the 
function, instruction P. The trace requests in Patch 4 il- 
lustrate that when the variable X is evaluated, it will be 
evaluated using the current variable scope of function 
FN1 , but that the global variable Y will be evaluated us- 
ing the appropriate variable scope for Y, which may be 
the entire program rather than the local scope of function 
FN1 . Those skilled in the art will appreciate that a variety 
of other patches are possible. 

[0048] Referring now to Figures 3A and 3B, illustrative 
examples of code fragment executables stored in an ex- 
ecutable machine-independent non-compiled format 
are shown. In particular, the exemplary machine-inde- 
pendent format shown are parse trees. In Figure 3A, the 
source code statement 'A = A + (B*3)' is shown, along 
with a corresponding parse tree that encodes this 
source code statement. The original source code line 
can be reconstructed by using depth-first search along 
the parse tree, using non-leaf nodes only after the first 
child branch has been used. Similarly, Figure 3B illus- 
trates a possible parse tree for the source code function 
Swap as shown. As the parse tree is read from left to 
right and upwards from the leaf nodes, the appropriate 
order of statements for the Swap function is retrieved. 
Those skilled in the art will appreciate that a parse tree 
can be represented using different formats, and that 
parse trees are only one possible format for encoding 
executable machine-independent code fragment exe- 
cutables. 

[0049] Figure 4 is an exemplary flow diagram of an 
embodiment of the Command Subsystem routine 400. 
The Command Subsystem routine will receive a com- 
mand from a user to either patch a compiled executable 
code file such as code file 132 or to execute an already 
patched executable code file such as patched code file 
1 82. In an alternate embodiment, patches can be added 
to a compiled executable code file that already contains 
patches (and can even patch already patched instruc- 
tions), as well as to a compiled executable code file with- 
out patches. If the user is currently patching a compiled 
executable code file, the routine will accept a variety of 
trace requests and code fragments to be added to the 
code file, will combine multiple patches if they are to be 
added at the same compiled instruction in the compiled 
executable code file, and will notify the Patching Sub- 
system 136 (Figure 1) and the Code Fragment Execut- 
ables Subsystem 138 (Figure 1) of the patches. If the 
user is executing an already patched executable code 
file, the routine can receive commands, relay them to 
the Patch Interpreter Subsystem 1 81 (Figure 1 ), and re- 



ceive and display to the user the results of the execution 
of the command. In one embodiment in which the Com- 
mand Subsystem 134 (Figure 1) provides interactive 
control over a patched executable code file, a user can 
5 determine whether or not to view the source code for 
patches {e.g., not viewing source code for disabled 
patches). 

[0050] The Command Subsystem routine begins at 
step 405 where a command is received from a user. The 

10 routine continues in step 410 to determine if the com- 
mand is to patch a compiled executable code file. If so, 
the routine continues to step 415 where it receives an 
indication of the executable code file to be patched. The 
routine then continues in step 420 to load information 

15 from the symbol table of the indicated executable code 
file, thus allowing the source code lines corresponding 
to the compiled executable code instructions to be dis- 
played to the user. The routine then continues to step 
425 where a request is received from the user that is 

20 related to patching the compiled executable code file. 
The routine continues in step 430 to execute the Proc- 
ess Patch Request subroutine to process the request. 
As is explained in greater detail with relation to Figure 
5, possible patch requests include adding various trace 

25 requests or code fragments, grouping and degrouping 
patches, and manipulating previously created patches. 
After the patch request has been processed in step 430, 
the routine continues in step 435 to determine if there 
are more patch requests from the user. If so, the routine 

30 returns to step 425 to receive the next patch request. 
[0051] If there are not more patch requests from the 
user, the routine continues to step 440 to sequence 
patches together when they will replace the same com- 
piled instruction. Since any given compiled instruction 

35 in the compiled executable code file can only be re- 
placed with a single patching instruction to a patch han- 
dler, multiple patches that have been associated with a 
single compiled instruction must be sequenced togeth- 
er. Additional steps may also need to be taken to ensure 

40 that all patches are executed and that the correct order 
of patch execution is followed. In the illustrated embod- 
iment, multiple patches associated with a single com- 
piled instruction are placed in a single patch handler for 
the patching instruction that will replace the compiled 

45 instruction. Alternately, multiple patch handlers could be 
used, with each patch handler transferring flow of exe- 
cution to the next patch handler in sequence and with 
the last patch handler returning the flow of execution to 
the compiled instruction following the patching instruc- 

50 tion. In either case, a sequence in which to execute the 
multiple patches must be selected. For example, all 
trace requests could be executed either before or after 
all code fragments. In the illustrated embodiment, the 
user indicates the sequence of patches when the patch- 
es es are created. 

[0052] After step 440, the routine continues to step 
445 to notify the Patching Subsystem 136 of the patch 
sequences to be added to the compiled executable code 
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file, including sequences of a single patch. The routine 
then continues to step 450 to notify the Code Fragment 
Executables Subsystem 138 of the code fragments, in- 
cluding created modules, that have been added as 
patches to the compiled executable code file. The rou- 
tine continues in step 455 to determine if there are more 
commands from the user. If so, the routine returns to 
step 405 to receive a user command, and if not, the rou- 
tine ends at step 499. 

[0053] If it is instead determined in step 410 that the 
received user command is not to patch a compiled ex- 
ecutable code file, the routine continues to step 460 
where an indication of a patched compiled executable 
code file is received. This patched code file will be exe- 
cuted on an indicated target computer system. In the 
illustrated embodiment, the patched code and any as- 
sociated patch handlers and code fragment executables 
will have been transferred to the indicated target system 
when the patching occurred. Alternately, the transferring 
could occur after step 460. The routine next continues 
to step 465 to determine if the patched code file is to be 
executed with interactive control by the user. If the 
patched executable code file is not to be executed in- 
teractively, the routine continues to step 470 where the 
Patch Interpreter Subsystem 181 is notified to execute 
the patched executable code file without waiting for in- 
teractive commands. If instead it is determined in step 
465 that the patched executable code file is to be exe- 
cuted interactively, the routine continues instead to step 
475 where the Patch Interpreter Subsystem 181 is no- 
tified to execute the patched executable code file in an 
interactive execution mode. 

[0054] The routine next continues to step 480 to re- 
ceive an execution-related command from the user. 
Such commands could include setting or removing 
break points, checking the current values of variables 
and expressions, or stepping through the execution a 
single line at a time. In the illustrated embodiments, the 
manipulation of patches does not occur during interac- 
tive execution, but such functionality could be provided 
in an alternate embodiment. In step 485, the routine no- 
tifies the Patch Interpreter Subsystem 181 of the com- 
mand, and in step 490 the results of the command ex- 
ecution are received from the Patch Interpreter Subsys- 
tem 1 81 and are displayed to the user. The routine then 
continues to step 495 to determine if there are more in- 
teractive execution commands from the user. If so, the 
routine returns to step 480 to receive the next user com- 
mand. After step 470, or if it is determined in step 495 
that there are not more interactive execution com- 
mands, the routine continues to step 455 to determine 
if there are more user commands. Those skilled in the 
art will appreciate that the Command Subsystem routine 
can be implemented in a variety of ways. For example, 
other top-level user commands than patching compiled 
executable code files and executing patched compiled 
executable code files could be processed by the routine. 
Alternately, separate routines could be used to patch a 



compiled executable code file and to execute a patched 
compiled executable code file. 

[0055] Figure 5 is an exemplary flow diagram of an 
embodiment of the Process Patch Request subroutine 
5 430. The Process Patch Request subroutine receives a 
user request related to patching the compiled executa- 
ble code file, determines the type of patch request, and 
satisfies the patch request. In the illustrated embodi- 
ment, the user indicates source code lines correspond- 
ing to compiled instructions in the compiled executable 
code file for patch requests, and the Code Patcher sys- 
tem 1 33 selects the appropriate compiled instruction for 
the indicated source code line when performing the re- 
quest. 

[0056] The subroutine begins at step 505 where it is 
determined if the patch request is to add a trace request 
to indicate when a source code line is executed. If so, 
the subroutine continues to step 510 to add the trace 
request to an appropriate patch handler, which will be 
referenced by a patching instruction that replaces a 
compiled instruction corresponding to the indicated 
source code line. If it is instead determined that the trace 
request is not to trace a source code line, the subroutine 
continues to step 515 to determine if the patch request 
is to add a trace request to indicate when a function in 
the compiled executable code file is executed. If so, the 
subroutine continues to step 520 to add a trace request 
to a patch handler for the first instruction of the indicated 
function, if the patch request is not to trace a function, 
the subroutine continues to step 525 to determine if the 
patch request is to add a trace request for a specified 
expression at a particular source line. If so, the subrou- 
tine continues to step 530 to add a trace request for the 
expression to a patch handler at the indicated source 
line. If the patch request is not to trace a specified ex- 
pression, the subroutine instead continues to step 535 
to determine if the patch request is to add a specified 
code fragment to the compiled executable code file. If 
so, the subroutine continues to step 540 to add the spec- 
ified code fragment executable to a patch handler at the 
compiled instruction corresponding to an indicated 
source line. The user can also indicate whether the 
patch is to substitute for the instruction or to be added 
in addition to the instruction, and when the patch is add- 
ed in addition to the instruction whether the patch is to 
be executed before or after the source code line. 
[0057] If it has been determined in steps 505, 515, 
525, and 535 that the patch request is not to add to the 
compiled executable code file patch statements that re- 
quire patch handlers, the subroutine continues to step 
545 to determine if the patch request is to create a code 
fragment module. If so, the subroutine continues to step 
550 where an invokable code module with multiple 
source code statements is specified by the user, and an 
associated code fragment executable module is created 
for the patched executable code file. If it is determined 
in step 545 that the patch request is not to create a code 
module, then the subroutine continues to step 555 to 
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determine if the patch request is to group patches to- 
gether or to degroup previously grouped patches into 
individual patches. If so, the subroutine continues to 
step 560 to perform the indicated grouping or degroup- 
ing. If the patch request is not to group or degroup patch- 
es, the subroutine continues to step 565 to determine if 
the patch request is to manipulate a patch or patch 
group. If so, the subroutine continues in step 570 to ma- 
nipulate the patch or the patches in a patch group as 
indicated. After step 510, 520, 530, 540, 550, 560, or 
570, or if it is determined in step 565 that the patch re- 
quest does not manipulate a patch or a patch group, the 
subroutine continues to step 590 where it returns. 
[0058] Figure 6 is an exemplary flow diagram of an 
embodiment of the Patching Subsystem routine 600. 
The Patching Subsystem routine is notified by the Com- 
mand Subsystem routine when patch sequences are to 
be added or manipulated for a compiled executable 
code file. The Patching Subsystem routine then creates 
the necessary patch handlers, patches the compiled ex- 
ecutable code file in the appropriate manner, and loads 
the patch handlers and the patched compiled executa- 
ble code file onto a target system. The routine begins at 
step 605 where one or more patch sequences are re- 
ceived for a compiled executable code file. This notifi- 
cation from the Command Subsystem 134 can also in- 
dicate that previously added patches have been manip- 
ulated (e.g., removed or disabled). The routine contin- 
ues in step 610 to select the next received patch se- 
quence to be added or manipulated, beginning with the 
first received patch sequence. The routine then contin- 
ues to step 615, where an appropriate patch handler is 
created if the selected patch sequence indicates that a 
patching instruction is to be added to the compiled ex- 
ecutable code file. Alternately, if an existing patch is be- 
ing changed, an existing patch handler can be accord- 
ingly modified or a new patch handler can be created to 
replace an existing patch handler. For example, if a pre- 
viously added patch is being removed, the original 
patched instruction can be reinserted in the compiled 
executable code file in place of the patching instruction. 
Alternately, if a patch handler is being disabled, the first 
instruction of the patch handler could be modified to 
cause a jump to the end of the patch handler or to the 
instruction following the patching instruction. Similarly, 
if a patch is being qualified, the patch handler for that 
patch can be modified to include evaluation statements 
to determine if the specified conditions are true. 
[0059] After step 615, the routine continues to 620 to, 
if a patching instruction needs to be added, replace the 
appropriate compiled executable code instruction with 
a patching instruction (e.g., a jump statement) to the cre- 
ated patched handler. If an existing patch handler is 
merely being modified, it will not be necessary to replace 
a compiled instruction with a patching instruction since 
the existing patching instruction will still be effective. 
While the illustrated embodiment uses a jump instruc- 
tion for patching instructions, those skilled in the art will 



appreciate that a patch handler can be invoked in a va- 
riety of ways, such as by using an interrupt mechanism 
or by including an identifier that will be resolved at exe- 
cution time to indicate an appropriate location in mem- 

5 ory on the target system. In addition, those skilled in the 
art will appreciate that a compiled transfer statement in- 
struction could be used as a patching instruction. After 
step 620, the routine continues in step 625 to determine 
if there are more patch sequences to be selected. If so, 

10 the routine returns to step 610 to select the next patch 
sequence, and if not, the routine continues to step 630. 
[0060] After patch handlers have been created or 
modified for each patch sequence and patching instruc- 
tions have been added to the compiled executable code 

15 file, the routine in step 630 loads the patched executable 
code file onto the target system. The routine then con- 
tinues in step 635 to load any created and/or modified 
patch handlers onto the target system. In the illustrated 
embodiment, the Patching Subsystem 136 does not 

20 perform memory management for target computer sys- 
tem 150, so the memory locations on the target system 
in which the created patch handlers will be loaded will 
not be known until execution time. Thus, the patching 
instructions inserted into the compiled executable code 

25 file merely reference the appropriate patch handler, with 
the reference to the appropriate memory location to be 
resolved at execution time. This type of reference reso- 
lution allows linking to be delayed until execution time. 
Thus, after step 635, the routine continues in step 640 

30 to update a Link Translation Table on the target system 
to reflect the unique identifiers for the created patch han- 
dlers. After step 640, the routine continues to step 645 
to determine if there are more patch sequences to re- 
ceive. If so, the routine returns to step 605 to receive 

35 patch sequences, and if not the routine continues to step 
690 and ends. 

[0061] Figure 7 is an exemplary flow diagram of an 
embodiment of the Code Fragment Executables Sub- 
system routine 700. The Code Fragment Executables 

40 Subsystem routine receives notifications from the Com- 
mand Subsystem 134 when code fragments are to be 
added to the compiled executable code file, creates ma- 
chine-independent non-compiled code fragment exe- 
cutables that can be interpreted by the Patch Interpreter 

45 Subsystem 181, and loads the created code fragment 
executables onto the target system. The routine begins 
in step 705 where code fragments to be added to the 
compiled executable code file are received from the 
Command Subsystem. The routine continues to step 

50 71 0 to select the next code fragment, beginning with the 
first code fragment. In step 715, the routine then creates 
a code fragment executable for the selected code frag- 
ment in a machine-independent format not specific to 
the target computer. In the illustrated embodiment, the 

55 code fragment executables are stored in parse tree for- 
mat. The routine then continues in step 720 to determine 
if there are more code fragments to process. If so, the 
routine returns to step 71 0 to select the next code frag- 
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ment, and if not the routine continues to step 725. 
[0062] After the code fragment executables have 
been created, the routine in step 725 loads the created 
code fragment executables onto the target system. The 
routine then continues to step 730 to update the Link 
Translation Table on the target system to reflect the ref- 
erences for the created code fragment executables. For 
example, if invokable code modules have been created 
for the patched compiled executable code file, an entry 
in the Link Translation Table can be used to resolve at 
execution time a reference to a code module, allowing 
flow of execution to be transferred to the appropriate 
memory location where the code fragment executable 
for the module is loaded in memory. Similarly, if varia- 
bles have been defined and made available to other por- 
tions of the code outside a self-contained variable scope 
(e.g., global variables), the Link Translation Table can 
be used to resolve references to those variables by oth- 
er portions of the code. Finally, if the code fragment ex- 
ecutables are loaded into memory separate from the 
patch handlers that will reference those code fragment 
executables, then the Link Translation Table can be 
used to resolve the references for each such code frag- 
ment executable. 

[0063] Those skilled in the art will appreciate that if 
the memory locations for code fragment executables 
are known at the time that the patches and patch han- 
dlers are created, it may not be necessary to use a Link 
Translation Table to resolve those references. For ex- 
ample, if code fragment executables are included with 
the patch handlers which reference them, then each 
such code fragment executable would not need a 
unique identifier that could be resolved through the use 
of the Link Translation Table. After step 730, the routine 
continues in step 735 to determine if there are more 
code fragments to receive. If so, the routine returns to 
step 705, and if not the routine ends at step 790. 
[0064] Figure 8 is an exemplary flow diagram of an 
embodiment of the Patch Interpreter Subsystem routine 
800. The Patch Interpreter Subsystem routine receives 
an indication of a patched executable code file to be ex- 
ecuted, loads the patched compiled executable code file 
as well as associated patch handlers and code fragment 
executables into memory, executes the non-patched 
compiled instructions as native code for the target sys- 
tem, and executes the patch statements in an interpret- 
ed manner. Those skilled in the art will appreciate that 
in an alternate embodiment, before execution time the 
Patch Interpreter Subsystem 181 or another subsystem 
could compile the target-independent code fragment ex- 
ecutables into compiled instructions that are native to 
the particular target system. In this situation, the Patch 
Interpreter Subsystem 1 81 would only be needed to re- 
solve references, such as for patch, handlers and code 
fragment executable modules, when such references 
are included in the patched compiled executable code 
file. 

[0065] The routine begins in step 805 where an indi- 



cation is received of the patched executable code file to 
be executed. In the illustrated embodiment, this indica- 
tion is received from the Command Subsystem 134 on 
the host computer system. In an alternate embodiment, 

5 the Patch Interpreter Subsystem 181 could receive in- 
structions directly from a user on the target computer 
system if the target system included the necessary in- 
put/output devices. The routine then continues to step 
81 0 to load the patch handlers and code fragment exe- 

10 cutables associated with the patched compiled execut- 
able code file into memory if they are not already stored 
in memory. The routine then continues to step 815 to 
ensure that the Link Translation Table reflects the cur- 
rent memory addresses for the code fragment executa- 

15 bles and the patch handlers. After step 815, the routine 
continues to step 820 where the patched compiled ex- 
ecutable code file is loaded into memory if it is not al- 
ready stored in memory. The routine then continues to 
step 825 to execute the Execute Patched Executable 

20 Code subroutine. The routine then continues to step 830 
to determine if there are more patched compiled exe- 
cutable code files to execute. If so, the routine returns 
to step 805, and if not, the routine ends at step 890. 
Those skilled in the art will appreciate that in an alternate 

25 embodiment, the Patch Interpreter Subsystem routine 
could execute multiple different patched executable 
code files at the same time. 

[0066] Figure 9 is an exemplary flow diagram of an 
embodiment of the Execute Patched Executable Code 

30 subroutine 825. The Execute Patched Executable Code 
subroutine receives and executes user commands if an 
interactive execution of the patched compiled executa- 
ble code file is in process. When a non-patched com- 
piled instruction is to be executed, it is executed as na- 

35 tive code. For each patch statement, the subroutine first 
determines if the statement is to be executed and then 
resolves link identifiers if necessary. The subroutine 
then satisfies trace requests by writing the specified 
trace information to a trace log on the target system, 

40 executes code fragment executables by interpreting 
them, and notifies the Code Patcher system 133 of the 
execution status after the instruction has been proc- 
essed. 

[0067] The subroutine begins at step 905 where it is 
45 determined if the current execution of the patched com- 
piled executable code file is to be done in an interactive 
mode. If so, the routine continues in step 91 0 to receive 
a user command. The subroutine then continues to step 
91 5 to determine if the received command is to execute 
50 the current instruction in the patched executable code 
file. If not, the subroutine continues to step 920 to exe- 
cute the user command, and then continues to step 925 
to notify the Code Patcher system 133 of the results of 
executing the command. For example, a user may wish 
55 to see a current value for a variable or to specify a break 
point at a spot in the patched compiled executable code 
file. After such a break point has been set, the user may 
indicate to continue execution in a non-interactive mode 
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until a break point is reached, thus causing execution to 
stop and returning execution of the patched executable 
code file to an interactive mode. After step 925, the sub- 
routine returns to step 905. 

[0068] If it was instead determined in step 905 that the 5 
execution of the patched executable code file is not cur- 
rently in interactive mode, or if it was determined in step 
915 that the user command was to execute the current 
instruction, the subroutine continues in step 930 to se- 
lect the next instruction in the patched executable code 10 
file, beginning with the first instruction. The subroutine 
then continues to step 931 to determine whether the cur- 
rent instruction is to be currently executed. For example, 
the current instruction could be a patching instruction for 
a patch that is disabled or that is qualified with a condi- 15 
tion that is not currently met in the current environment. 
If the instruction is not to be currently executed, the sub- 
routine continues to step 970 where the Code Patcher 
system 133 will be notified of the status of execution of 
the current instruction if execution is occurring in an in- 20 
teractive mode. Those skilled in the art will appreciate 
that when an entire patch handler consisting of multiple 
patch statements has been disabled or is not qualified, 
the status of the patch handler can be indicated in a va- 
riety of ways. For example, a flag could be set when the 25 
patch handler was entered indicating that patch state- 
ments are not to be currently executed while the flag is 
set, with the flag being reset when the end of the patch 
handler is reached. Alternately, the patch handler could 
cause the flow of execution to skip any disabled patch 30 
statements. 

[0069] If it is determined in step 931 that the current 
instruction is to be executed, the subroutine continues 
to step 932 to determine if the instruction is a compiled 
instruction. If so, the subroutine continues to step 933 35 
to execute the current instruction in native mode on the 
target system, and then continues to step 970. If it is 
instead determined in step 932 that the current instruc- 
tion is a non-compiled patch statement or patching in- 
struction, the subroutine continues in step 935 to deter- 40 
mine if the current instruction includes a link identifier 
reference that needs to be resolved. If so, the subroutine 
continues in step 940 to use the Link Translation Table 
to resolve the link identifier so that the current position 
in memory for the associated code can be accessed. 45 
After step 940, or if it is determined in step 935 that a 
link identifier is not present, the subroutine continues in 
step 945 to determine if the current instruction is a trace 
request. If so, the subroutine continues to step 950 to 
write the specified trace information to a trace log on the 50 
target system that can be retrieved by a user on the host 
computer system 1 00. If the trace request includes var- 
iable or expressions to be evaluated, they will be eval- 
uated in the context of the current variable scope. 
[0070] If it is instead determined in step 945 that the 55 
current instruction is not a trace request, the subroutine 
continues to step 965 to execute the code fragment ex- 
ecutable by interpreting it within the context of the cur- 



rent variable scope. For example, a global variable X 
may be defined, with the current flow of execution first 
entering Function 1 with a variable X that is local to that 
function and then entering a Function 2 with a distinct 
local variable X for that function. If patch code within 
Function 2 requires the evaluation of variable X, its cur- 
rent variable binding within the scope of Function 2 will 
be used for the evaluation. Those skilled in the art will 
appreciate that the current variable scope can be deter- 
mined in a variety of ways, such as by using symbol ta- 
ble information from the patched executable code file or 
the current variable block on the stack. After step 950 
or 965, the subroutine continues at step 970 to notify the 
Code Patcher system 1 33 of the status of executing the 
current instruction if execution is occurring in interactive 
mode. The subroutine then continues to step 975 to de- 
termine if there are more instructions to be executed in 
the patched compiled executable code file. If so, the 
subroutine returns to step 905, and if not the subroutine 
returns in step 990. 

[0071] From the foregoing it will be appreciated that, 
although specific embodiments of the invention have 
been described herein for purposes of illustration, vari- 
ous modifications may be made without deviating from 
the spirit and scope of the invention. Accordingly, the 
invention is not limited except as by the appended 
claims. 



Claims 

1 . A method for modifying an executable file including 
a plurality of compiled instructions, the compiled in- 
structions natively executable on a target computer 
but not on a source computer, the modifying per- 
formed under control of the source computer with- 
out recompiling or relinking or rewriting the execut- 
able file, the method comprising: 

under control of the source computer, 

(a) loading the executable file onto the tar- 
get computer; 

(b) receiving a plurality of indications to 
modify the loaded executable file, each in- 
dication specifying one of the compiled in- 
structions in the loaded executable file and 
at least one non-compiled executable in- 
struction to be added to the loaded execut- 
able file; 

(c) modifying the loaded executable file by, 
for each indication, 

creating an instruction group including 
the specified at least one non-com- 
piled executable instruction; 
converting the instruction group into 
an executable non-compiled format 
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not specific to the target computer; and 
replacing the specified compiled in- 
struction in the loaded executable file 
with an executable patch instruction 
associated with the converted instruc- 5 
tion group, the patch instruction when 
executed to transfer flow of execution 
to the converted instruction group with 
which the patch instruction is associat- 
ed; and 10 

(d) loading the converted instruction 
groups into at least one memory area on 
the target computer, the at least one mem- 
ory area distinct from a memory area on the 15 
target computer containing the loaded ex- 
ecutable file; and 

under control of the target computer, executing 
the modified loaded executable file by, as the 20 
flow of execution sequentially reaches each ex- 
ecutable instruction, 

(e) when the executable instruction is a 
non-compiled executable instruction from 25 
an instruction group, interpretively evaluat- 
ing the executable instruction; 

(f) when the executable instruction is a 
patch instruction, transferring flow of exe- 
cution to the loaded associated converted 30 
instruction group; and 

(g) when the executable instruction is a 
compiled instruction, natively executing 
the compiled executable instruction, 

35 

so that additional functionality is exhibited when the 
modified loaded executable file is executed on the 
target computer. 

2. The method of claim 1 wherein after performing 40 
steps (a)-(g) afirst time, steps (b)-(g) are performed 

a second time without performing step (a) a second 
time such that the modified loaded executable file 
is further modified and then executed without re- 
loading the executable file. 45 

3. A computer-implemented method for adding in- 
structions to be executed to an executable compiled 
file without recompiling or rewriting the file, the 
method comprising: 50 

receiving an indication to modify the compiled 
file, the indication specifying a compiled in- 
struction in the compiled file and at least one 
executable instruction to be added; 55 
modifying the compiled file by, 

creating a patch group including the spec- 



ified at least one executable instruction; 
and 

replacing the specified compiled instruc- 
tion in the compiled file with a patch instruc- 
tion such that flow of execution will transfer 
to the created patch group upon execution 
of the patch instruction; and 

storing separate from the patch group the mod- 
ified compiled file including the patch instruc- 
tion, 

so that instructions in the patch group will be exe- 
cuted when the modified compiled file is later exe- 
cuted. 

4. The method of claim 3 wherein the modified com- 
piled file is executed on a separate computer, and 
including: 

supplying to the separate computer at least one 
direction related to the execution of the modi- 
fied compiled file; and 

displaying received results of performance of 
the supplied direction. 

5. The method of claim 3 wherein without removing 
the patch instruction from the modified compiled 
file, the patch group is disabled such that the in- 
structions in the patch group are not executed when 
the modified compiled file is executed. 

6. A computer-implemented method for executing a 
modified compiled file including a plurality of original 
compiled instructions and at least one patch instruc- 
tion in place of an original compiled instruction, 
each patch instruction when executed to transfer 
flow of execution to an associated patch group in- 
cluding a plurality of instructions, the method com- 
prising: 

loading the modified compiled file and the as- 
sociated patch groups into memory; and 
executing the modified compiled file by, as the 
flow of execution reaches each executable in- 
struction, 

when the executable instruction is an orig- 
inal compiled instruction, natively execut- 
ing the executable instruction; 
when the executable instruction is one of 
the patch instructions, transferring flow of 
execution to the associated patch group for 
the patch instruction; and 
when the executable instruction is one of 
the plurality of instructions from a patch 
group, interpretively evaluating the execut- 
able instruction. 
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7. A computer system for adding instructions to be ex- 
ecuted to an executable compiled file without rec- 
ompiling or rewriting the file, comprising: 

a command subsystem for receiving indica- 5 
tions to modify the compiled file, each indica- 
tion specifying a compiled instruction in the 
compiled file and at least one executable in- 
struction to be added; and 

a patching subsystem for modifying the com- 10 
piled file by creating for each received indica- 
tion an associated patch group including the 
specified at least one executable instruction, 
and by replacing the specified compiled instruc- 
tion in the compiled file with a patch instruction 15 
such that flow of execution will transfer to the 
associated patch group upon execution of the 
patch instruction. 

8. A computer-readable medium containing instruc- 20 
tions for controlling a computer system to add in- 
structions to be executed to an executable compiled 

file without recompiling the file, by: 

receiving an indication to modify the compiled 25 
file, the indication specifying a compiled in- 
struction in the compiled file and at least one 
executable instruction to be added; and 
modifying the compiled file by, 

30 

creating a patch group including the spec- 
ified at least one executable instruction; 
and 

replacing the specified compiled instruc- 
tion in the compiled file with a patch instruc- 35 
tion such that flow of execution will transfer 
to the created patch group upon execution 
of the patch instruction. 

9. The computer-readable medium of claim 8 wherein 40 
the computer system is further controlled by, after 

the modifying of the compiled file executing on atar- 
get computer the modified compiled file by, when 
an instruction to be executed is the patch instruc- 
tion, indicating an instruction in the created patch 45 
group as a next instruction to be executed. 

10. The computer-readable medium of claim 9 wherein 
the computer system is further controlled by, after 

the executing of the modified compiled file, perform- 50 
ing the modifying and the executing again without 
reloading the compiled file into memory. 



55 



EP 1 014 263 A2 



£ 



3 

C 

E 

c 
a 

aj 



CO 



o 



co 



CM 
CO 



CO 



CO 
CO 



CO 

co 



tcr 


em 


o 


00 






& 




o 






3 










o 




«— » 








Oh 





CXJD 
C3 



1— 

3 

C3 





C/l 


c 








r- 




c 










3 


eg 










X 


-a 




o 




a 





5 -o 

C 



C 



OO 
CO 



CO 
O 



(J 



T 

JL 



A 



o 

*> 
<u 
-a 

Oh 

o 

3 

cx 

C 



A 
T 



- 3 









o 




c 

u O 






irage devi 




netwo 
connecti 














oo 









C2> 



c 

<& 

oo 
oo 



£ 

o 



O 
4= 



A 

_L 



cm 



1 5 



3 



CM 



tf o 
o v3 

1 1 

C § 

o 



CM 



CO 



CM 



c3 
O 



CO 
CM 



to 



CM 
CO 

XI o 

C3 C-> 



0J 



So 

s; 



3 
c 

U 



A 

JL 



A 

JL 



to 



CO 



o 
B 



J_ 



3 



co 

CO 



c3 

-a 

o 
U 



CO 



CO 
CO 



co 
oo 



T3 £ 

C D 

fa JD 
O 3 



00 c 

o > 
oo 

CU 3 



oo 



3 X> oo 

£§•§ 

o 
U 



16 



EP 1 014 263 A2 



Instr N 

<a=a+c> 



Instr N+l 
<Ifa>20> 



Instr N+2 

<Then Call FN l(a)> 



Instr N+3 
<Else a=()> 



Instr N+4 
<End Ifi> 



Instr N+5 
<While bo0> 



Instr N+6 
<Print "b= n , b> 



Instr N+7 
<End While> 



FN1(X) 



Instr P 

<IfTime( )="PM"> 



Instr P+l 

<Then Print 'Temp 
High:", x> 



Instr P+2 
<End If> 



Instr P+3 
<RETURN> 



Fig. 2 A 



PATCH 1 



Instr N+l 



Instr N+2 



PATCH 2 



Instr N+4 



Instr N+5 



PATCH 3 



Instr N+7 



FN1(X) 



PATCH 4 



Instr P+i 



Instr P+2 



Instr P+3 



Fig. 2B 



Patch Handler PATCH 1 



<save state> 



Trace "Trace: Patch 1" 



Instr N 



<restore state> 



Patch Handler PATCH 2 



<save state> 



Trace "Trace A:", a 



ELSE a=l 



<restore state> 



Patch Handler PATCH 3 



<save state> 



b=b-l 



call Fn2(b) 



Instr N+6 



<restore state> 



Patch Handler PATCH 4 



<save state> 



Trace "Fnl",x 



Trace "Global Y y 



Instr P 



<restore state> 



FN2(X) 



Instr M 

<ify = TRUE> 



Instr M+l 

<Then Print M Fn2:", x> 



Instr M+2 
<RETURN> 



17 



EP 1 014 263 A2 



a = a + (b * 3) 




Fig. 3 A 



Function Swap (Ptr C, Ptr D) 
Global X = Value at Ptr C 
Value at Ptr C = Value at Ptr D 
Value at Ptr D = Global X 

RETURN 



Swap (Ptr C, Ptr D) 



/ \ 

/ \ Value at Ptr C Value at Ptr D / 
Global X Value at Ptr C Value at Ptr D 



Global X 



Fig. 3B 



18 



EP 1 014 263 A2 



/Command SubsystemV^ 
I Routine J 



405 



Receive command 






Receive indication of 
executable code to 
patch 


if 420 




Load executable code 
symbol table 


*v 425 




Receive patch request 


1 430 




Process patch 
request 


Yes More patch \! 



requests? 



LNo 



Sequence patches 
together 



445 



Notify Patching 
Subsystem of patch 
sequences 



460 



450 



Notify Code Fragment 
Executables 
Subsystem of code 
fragments 




Receive indication of 
patched executable 
code to execute on 
target computer 
system 




470 



Notify Patch 
Interpreter Subsystem 
to execute code 
without waiting for 
interactive commands 



Notify Patch Interpreter 
Subsystem to execute 
code in interactive 
execution mode 



480 



Receive command 



485 



Notify Patch 
Interpreter Subsystem 
of command 



490 



Receive results of 
command execution 




Fig. 4 



19 



EP 1 014 263 A2 



, 43° 

Process Patch \ 
lequest Subroutine/ 



510 



Add trace request for 
indicated source line 



.Yes, 



Trace source 
line? 



No 



^515 



Trace function? 



Yes 



520 



Add trace request for 
first code line of 
indicated function 



530 



Add trace request for 
expression at 
source line 



Yes. 



No 



Trace ^^525 
^expression at 
source 
line? 



| No 

.535 

Add code \^ Yes 
fragment? 



540 



Add specified code 
fragment at indicated 
source line 



No 



550 



Create code module 
with specified code 



Yes, 



Create code 
module? 



545 



iNo 



.555 

jroup/degroupV Yes ^ 
patches? 



560 



Group indicated 
patches or degroup 
indicated group 



No 



570 



Manipulate patch 
group as indicated 



Yes 



Manipulate 
patch groups? 



J65 



RETURN 



590 



Fig. 5 



20 



EP 1 014 263 A2 



600 



/hatching Subsystem^ 
\^ Routine J 



605 



Receive patch 
sequences for 
executable code 



610 



Select next patch 
sequence 



615 



Create patch handler 
for selected patch 
sequence 



620 



Replace executable 
code line for patch 
sequence with jump to 
created patch handler 




Load patched 
executable code onto 

target computer 
system 



635 



Load created patch 
handlers onto target 
computer system 



640 



Update target 
computer system Link 
Translation Table to 
reflect created patch 
handlers 



Yes 




Fig. 6 



21 



EP 1 014 263 A2 



Code Fragment 
Executables Subsystem 
Routine 



700 



Receiv 
fragme 
executa 


e code 
nts for 
Die code 


► 


710 


\ Select next code 
fragment 




715 


Create target- 
independent code 
fragment executable 




Load created code 
fragment executables 
onto target computer 
system 



730 



Update target 
computer system Link 
Translation Table to 
reflect created code 
fragment executables 




Fig. 7 



22 



EP 1 014 263 A2 



Patch Interpreter 
Subsystem Routine 



805 



Receive indication of 
patched executable 
code to be executed 



810 



Load patch 
code fn 
executat 
memory if 


handlers & 
igment 
>les into 
necessary 




r 815 



Update Link 
Translation Table to 
reflect current memory 
addresses for code 
fragments and patch 
handlers 



820 



Load patched 


executable code into 


memory 




825 


Execute Patched 




Executable Code 






Fig. 8 

23 



EP 1 014 263 A2 



Execute Patched 
Executable Code 
Subroutine 





910 


Yes 


Receive command 


< « 




r 







920 





No 


. Yes 








930 




Select next 




instruction 



Execute command 



925 



Notify Code Patcher 
of execution results 



940 



Use Link Translation 
Table to resolve Link 
Identifier 



Yes 



Yes 



950 




933 



Execute 
instruction 
in native 
mode 



Write trace 
information to 
Trace Log 



Interpret executable 
code fragment within 
current function/file 
context 



970 



Notify Code Patcher 

of status if 
interactive execution 




Yes ^ More 

instructions^ 



c 



RETURN 



3 



Fig. 9 



24 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



III 



(11) 



(12) 



EUROPEAN PATENT APPLICATION 



III 



EP1 014 263 A3 



(88) 


Date of publication A3: 


(51) lntCl7: G06F 9/445 




18.06.2003 Bulletin 2003/25 






(43) 


Date of publication A2: 








28.06.2000 Bulletin 2000/26 






(21) 


Annliration numhpr 99310012 2 






(22) 


Date of filing: 13.12.1999 






(84) 


Designated Contracting States: 


(72) 


Inventor: Tinker, Jeffrey L. 




AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 




Kenmore, Washington 98027 (US) 




MC NL PT SE 








Designated Extension States: 


(74) 


Representative: Driver, Virginia Rozanne et al 




AL LT LV MK RO SI 




Page White & Farrer 








54 Doughty Street 


(30) 


Priority: 14.12.1998 US 212182 




London WC1N 2LS (GB) 


(71) 


Applicant: APPLIED MICROSYSTEMS 








CORPORATION 








Redmond, Washington 98072-9702 (US) 







(54) Method and system for modifying executable code to add additional functionality 



(57) A system for modifying a compiled executable 
code file by adding patches that add functionality when 
the modified executable code file is executed. The mod- 
ifying is performed without recompiling, relinking or re- 
writing the code file. Adding a patch involves creating a 
patch handler which when executed causes the patch 
statements to be executed, and may involve replacing 
one or more existing compiled instructions in the file with 
patching instructions to transfer flow of execution to the 
appropriate patch handler. The instructions replaced by 
the patching instructions can also be added to the patch 
handler. Patches can also include code statements 
which form a complete module, such as an invokable 
routine, which can be referenced by other patch state- 



ments to cause the module to be executed. Specialized 
trace requests can also be added as patch statements. 
The trace requests will make specified information 
about the current execution of the executable code file 
available to a software developer. Patch statements can 
include variables and expressions that will be evaluated 
in the context of the appropriate current variable scope, 
regardless of whether the scope is defined within the 
patch or by existing compiled instructions. After patches 
have been added, they can be disabled so as to prevent 
their execution without removing the patching instruc- 
tions from the compiled executable file. Patches can al- 
so be qualified with conditions such that the patch will 
be executed only when the conditions are true at the 
time of execution. 
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